Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d21/dvpcla.arc/DVPCLA.INF

Text File | 1990-03-26 | 14KB | 273 lines

If you have an interest in remote access, networking, DESQview, and
other high-tech productivity tools, the following may be of interest:

Recently, I was offered a project to investigate the use of remote
access software. Since most of my customers use DESQview, that's
where I did the development. My findings were that it is possible and
relatively easy to gain the effects of multi-processing and
multi-tasking by the combination of DESQview and pcANYWHERE III (or
vice versa, as will be discussed below). In addition, combined with a
network such as LANtastic, running on either or both ends of a
pcANYWHERE phone connection, you have the makings of one very nice
operating system!

First DESQview:

DESQview 2.26 offers many subtle refinements. Of particular note for
this discussion are the capabilities of dealing with interrupt driven
programs, such as the telecommunications programs familiar to us all,
and remote access software.

On the broad level of refinement, DESQview 2.26 now supports 4 COM
ports directly, as opposed to 2 that it supported in earlier
versions. (Actually, since version 2 it has been possible to use more
than 2 COM ports, but now it's easier.) Also, DESQview will now
retain different shift keys (such as the caps lock, scroll lock,
etc.) in each window. This means that different windows can use the
keyboard independently.

On a more subtle level of refinement, DESQview has a growing list of
Application Program Interface (API) users. The DESQview API is a way
for other programs to tie into the capabilities of DESQview. This
means that more programs are becoming DESQview aware, which makes for
at least good performance improvements, and in some cases a make or
break situation for something to successfully run in DESQview.  (As a
side note, the DESQview API is an excellent set of tools for
developing DESQview aware programs, not surprisingly.)

Which leads to pcANYWHERE III.

pcANYWHERE III is used to log onto one computer from another computer
by use of a modem or a direct connection (via a null modem cable, as
example). By running pcANYWHERE through the DESQview API Debugger, I
noted that pcANYWHERE makes API calls which serve to not require more
CPU time than is necessary. I did not take the time to check the
entire program, but would not be surprised if pcANYWHERE had begin
and end critical sections for when sections of it's code were best
not interrupted by DESQview servicing another program.  Once you've
got the DESQview API, it's not that difficult to enhance a program
for optimal performance in DESQview, and there is a lot you can do.

pcANYWHERE III consists of a number of related programs which have a
consistent interface. In general it is very easy to set up and use.
The basic install instructions are to choose a directory and copy the
stuff from two 360K floppy disks. Once that's done, you set up
Anywhere.exe and Aterm.exe, by running them and specifying the COM
port, screen colors and any names, passwords and phone numbers you
want to use. The defaults for everything else seemed fine.
Additionally, pcANYWHERE comes with DESQview program information
files, which made setup for DESQview as easy as using Add a Program,
telling DESQview where the files where, highlighting the files and
pressing Enter.

Aterm.exe, the software used to connect to the host is very slick.
It shows about 64 different modems that it supports, and supports
baud rates from 50 to 57600, plus auto sensing. Anywhere, the host
software is equally slick. As one example, there are 32 different
terminal types, ranging from Ampex 230 to Zenith, and PC MacTerm,
which means you can also use it for a PC to Macintosh interface.
Both programs offer a wealth of options, and make for a very complete
package, and the memory requirement of the different programs is
small.

The sessions I ran required four of it's programs:

- Anywhere.exe, software running on the host,
- Aterm.exe, the software running on the calling computer,
- Asend.exe, the file transfer program, and
- Alogoff.exe the program to terminate the call.

To call another computer, you run Aterm.exe and select a number to
dial. When you connect with a machine that is running Anywhere (the
host mode software of pcANYWHERE), you first log in by providing a
password. After logging in, I had access to the DOS prompt and all of
the resources the computer had to offer.

On the side of providing system security, Anywhere is reasonably
useful. On the host machine, you use the user's password to let the
caller run a program immediately after logging on, or a series of
programs serially, or provide open access. Further, if on a network,
you can use the network's resources to control what a user is capable
of accessing and doing. When a user logs off, you can configure
Anywhere.exe to reset everything down to re-booting the computer, or
just leave the session where the user left it. This latter part is
great for putting something to work and getting back to it later.

The host computer that I logged into was on a network, and once at
the DOS prompt, I was able to log into other servers on the network.
This gave me the opportunity to try a reasonably broad assortment of
programs, which included Lotus, Paradox, Framework, Right Hand Man,
Microsoft Word, Word Perfect, Turbo, Tax, Turbo C, a bunch of
graphics programs Turbo C, and DESQview, of course.

On a few sessions I logged in to the host and ran DESQview on the
remote computer. In DESQview, I ran Paradox 3 in one window, a DOS
(3.3) window and Microsoft Word 5.0 in another window. They worked
okay, but at one point my computer got confused and started switching
between the Paradox and DOS windows at will. It was pretty bizarre.
Paradox seemed to want to be in front, but this was cleared up by
switching back to the Paradox window, exiting Paradox, and then
starting it again.

On another occasion I was calling from a DESQview window. I logged
in, then ran DESQview on the remote computer. I didn't think it would
work. But it did! It did not work well, however, as DESQview (the
remote one, not the local one) got confused about keyboard input.
It's a small enough thing that I'm sure it's solvable, but I didn't
take the time to play with it.

As an aside, running a copy of DESQview from a DESQview window, even
when that window gets its memory and CPU from another computer, is
admittedly a little extreme, though I find it rather interesting, if
only for an indication of the robustness of pcANYWHERE and for a
promising glimpse of what is in store by way of multi-tasking &
multi-processing. And not just in the future.

Almost all programs worked fine, as long as they are not configured
for a video output greater than the capability of your equipment. If
that inadvertently happens, the screen sometimes displays
indecipherable, blinking rubbish, and sometimes pcANYWHERE will pop
up and tell you that the video mode is not-supported.

In either of these events, the program you are running (as well as
pcANYWHERE) is still functional. And if you know your way out of the
program blind, you can back out gracefully. If not you can terminate
the session.

Depending on the configuration of the host software, it will drop
what you are doing, or maintain it's position when you disconnect.
Aterm has a built-in screen refresh function that helps when the
screen gets gunged up, but it didn't always work, at which point,

I used a 2400 baud (Practical Peripherals) modem, and when running
graphics-based programs (not all of which worked well), the output is
obnoxiously slow. It is not surprising as a screen of graphics
information can require between 64K and 512K of memory. At 2400 bits
per second, even though pcANYWHERE supports a data compression
algorithm, it takes a while. A 9600 baud modem would help a lot, and
ISDN should make this type of connection as fast as running it on
your local disk drives, eventually....

In spite of the slow screen up-dates, your computer (or window) takes
on the attributes of the computer you are calling. So if you are
running a 10 Mhz AT, and log onto a 33 MHz '386, you get the
computing power of the 33 MHz machine. Not bad. Even with slow screen
updates.

The only change I had to make in any program was with Futuresoft's
Right Hand Man productivity software. Right Hand Man is intended for
network use and does everything I'd always hoped SideKick would do.
As it worked out, Borland went astray with SideKick and Futuresoft
grabbed the ball and did a wonderful job with it. (If you don't use
DESQview, and even if you do, you should consider using this.)
Anyway, I used Quarterdeck's Manifest to check the interrupts
required by pcANYWHERE and Right Hand Man and found that, among other
things, Right Hand Man checks the hardware interrupts when it starts
up; one of which is used by the modem, The end result was that Right
Hand Man disconnected the modem when it innitialized.

Anyway, I'd previously talked to the people at Futuresoft about a
problem I had with Right Hand Man and LANtastic, and found that
although Right Hand Man will grab all of the hardware interrupts, it
doesn't need to use them. As a result of this, I used an /i0d
instruction to exclude IRQ 5, which is one of the IRQ lines that may
(and is, in my case) used for LANtastic's LANBIOS program, from Right
Hand Man, and only had to add an 0c instruction to exclude COM1 (IRQ
4), which is used for the Modem. And the problem went away. After
that Right Hand Man worked flawlessly with everything I tried.

Two surprising elements that I didn't immediately resolve were that
after running some graphics based programs, pcANYWHERE would slow
down to a character of information about every second. A short look
through the manual (which is okay), lead me to a chapter on
customizing pcANYWHERE. There the manual indicated that shutting off
automatic graphics detection would improve performance. So I did.
Sometimes it cleared the problem. When it doesn't, terminating the
session and calling back was the resolution. Secondly, the file
transfer scheme, though easy to use, is pitifully slow. As example,
it took 12 minutes to transfer a 64K file. One possible solution is
that if you are using DESQview, it would probably be easy to fire off
DSZ.EXE in another window... Haven't tested that yet, but I expect
problems getting pcANYWHERE to recognize the com port after a DSZ
session.

So, pcANYWHERE is pretty good. The host software will also work as a
TSR, which means that you can load it, and forget about it's being
around. When a call comes in, it'll pick up the call and go from
there. The only significant down side is if you are going to use bit-
mapped graphics-based programs, or if you want quick response from
the screen, consider getting 9600 baud modems (which makes for a
convinient excuse to get 9600 baud screamer).

Back to DESQview

On separate occasions, I ran the pcANYWHERE host program and terminal
program from DOS, in a DESQview window, and, as indicated above, ran
DESQview from the remote terminal. In all cases the great LANtastic
Netware was running happily in the host and terminal computers. One
of the joys of LANtastic is that it does what you want it to, and is
transparent to use.

On all occasions that I ran pcANYWHERE from a DESQview window, I was
able to run programs in other windows, off of my local network, as
well as remotely. According to the pcANYWHERE documents, you can run
2 pcANYWHERE sessions concurrently with DESQview, and use other
windows locally. In combination with pcANYWHERE III, and some trick
software from Novell, you can substantially increase the number of
remote access windows you can run under DESQview. I think the number
is around 12.

On one occasion that I ran DESQview remotely, I ran three windows,
and gave them something to do, then logged off. Later, I called back,
and the sessions had continued to process while I was away.  Nice.
Supposedly, while your three programs are running, someone on the
host machine can use other windows locally. Nicer.

For DESQview and multi-user applications alla pcANYWHERE, you pretty
much need a 386 based computer. The reason is that when you run
something from a pcANYWHERE host, you are effectively taking over the
host computer, and everything you do is displayed on the host's
screen. By using DESQview-386 pcANYWHERE can run in it's own window,
or you can log on and run DESQview remotely.

Using DESQview with less than a 386 means that it can't run programs
that write directly to the video memory in a DESQview background
window, _and_ actually have the program run in the background. If you
do, the background will bleed through to the foreground. Running
programs that write directly to the video memory requires what what
Quarterdeck calls "text/graphics virtualization" in Change a Program
be set to "Y" to virtualize both text and Graphics. And for that to
work, you need a 386 and DESQview-386.

With this requirement fulfilled you have one very flexible operating
system that can span from a single computer to a wide area network.
As regards reliability, in about 10 hours of testing, neither the
host computer nor the calling computer crashed, except, ironically
when I ran Manifest remotely. Pretty good.

What all this amounts to is that you can use DESQview to perform both
multi-user and multi-tasking capabilities. As part of the deal, you
also get multi-processor capacities. Plus access to full networking
abilities on both sides of the phone connection. Pretty nifty. And
makes running stuff on a distant computer a breeze.

So, pcANYWHERE is a good investment, and in combination with
DESQview-386, creates the capability of having multi-tasking and
multi-user capabilities, with the results of the limits of DOS being
pushed back, yet again.


Tracy Lebenzon
TSL Systems Consulting
[phone]
(Authorized dealers of all the stuff above)


PCRelay:POVERTY -> INTELEC-NET * NorthWestern Region
4.10ß12A           Poverty Rock +Seattle WA+ 206-232-1763 HST38k
---
 ■ QNet 2.04: QuickLink:CAL-STAR [phone] Redding, Ca 19.2 HST S/R Host